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Abstract 


Stateflow is a widely used modeling framework for embedded and cyberphysical sys- 
tems where control software interacts with physical processes. In this work, we present a 
framework and a fully automated safety verification technique for Stateflow models. Our 
approach is two-folded: (i) we faithfully compile Stateflow models into hierarchical state 
machines, and (ii) we use automated logic-based verification engine to decide the valid- 
ity of safety properties. The starting point of our approach is a denotational semantics 
of Stateflow. We propose a compilation process using continuation-passing style (CPS) 
denotational semantics. Our compilation technique preserves the structural and modal be- 
havior of the system. The overall approach is implemented as an open source toolbox that 
can be integrated into the existing Mathworks Simulink/Stateflow modeling framework. 
We present preliminary experimental evaluations that illustrate the effectiveness of our 
approach in code generation and safety verification of industrial scale Stateflow models. 


1 Introduction 


The widespread deployment of cyberphysical systems in safety critical scenarios like automotive, 
avionics, and medical devices, has made formal and automated analysis of such systems neces- 
sary. This is witnessed by the sheer number of extensive approaches proposed in the verification 
community. Stateflow [22] is a widely used modeling framework for embedded and cyberphys- 
ical systems where control software interacts with physical processes. Specifically, Stateflow is 
a toolbox developed by MathWorks Inc. that extends Simulink [20] with an environment for 
modeling and simulating reactive systems. A Stateflow diagram can be included in a Simulink 
model as one of the blocks interacting with other Simulink components using input and output 
signals. Stateflow is a highly complex language with no formal semantics!: its semantics is only 


*This work was partially supported by the ANR-INSE-2012 CAFEIN project, CNES project No. R-S16/BS- 
0004-045 and NASA Contract No. NNX14AI09G. 
1At least not provided as a reference by the tool provider. 


T.Eiter and D.Sands (eds.), LPAR-21 (EPiC Series in Computing, vol. 46), pp. 144-161 


Analysis of Stateflow models Bourbouh, Garoche, Garion, Gurfinkel, Kahsai, Thirioux 


described through examples on the MathWorks website [22] without any formal definition. A 
Stateflow diagram has a hierarchical structure, which can be either arranged in parallel in which 
all states become active whenever the diagram is activated; or sequentially, in which states are 
connected with transitions and only one of them can be active. 

Over the years several approaches have been proposed for the analysis of Stateflow diagrams. 
Such approaches often lack one or many of the following desired features: (i) a convincing formal 
semantics; (ii) a faithful compilation that preserves the hierarchical structure of the Stateflow 
model; (iii) fully automated analysis engine; and last but not least (iv) an open source tool 
that is easy to use and able to handle realistic models. The aim of this paper is to provide a 
framework in which all those points are properly addressed. We based our work upon a series of 
papers by Hamon [15, 14, 16] providing operational and denotational semantics for Stateflow, 
designing interpreters for Stateflow. 

A CPS semantics for Stateflow. The starting point of our approach is the expression of the 
denotational semantics of Stateflow [14] as a pure continuation-passing style (CPS) denotational 
semantics. CPS has been proposed in the 70s by Plotkins [24] for A-calculus call-by-value 
semantics and later developed for efficient compilation means, for example in the long line of 
Danvy’s works, e.g., [18] and Appel’s book [3]. As recalled by Danvy, CPS terms can be simply 
expressed yet enjoy a number of useful properties, e.g., “offering a good format for compilation 
and optimization”. The following equations define the Plotkin’s call-by-value CPS rules: 


[z]k = Ke 
[Ave] K = K (Ax: Ak- [e] &) 
[eoei] « =~ [eo] (Avo-fe1] (Avi: vo v1 &)) 


The key idea is to associate to each function an additional argument, the explicit contin- 
uation « : t > t. This continuation is an endomorphic map over t values on which control 
is explicitly modeled: function calls, intermediate values, evaluation order, etc. In compila- 
tion, CPS $-reduction amounts to characterize a global continuation, which, when evaluated, 
produces the generated code. 


Contributions. This paper makes the following contributions: 


e We adapted Hamon’s denotational semantics [14] to a pure CPS semantics, solving some 
of its flaws (see §2.2). 


e We instantiate such CPS semantics for different uses, such as a model interpreter and a 
code generator for Stateflow models. Such framework has several advantages, including a 
formal semantics of Stateflow that preserves the hierarchical structure of the model. 


e We implemented the general CPS semantics and the proposed instantiations in OCaml: 
an interpreter and a code generator both for imperative code and Lustre automaton. 


e The Lustre automaton code generator from Stateflow has been implemented and inte- 
grated in COCOSIM [17] — an automated analysis framework for Simulink models. Co- 
CoSIM among other features provides an intuitive user interface that facilitates the mod- 
eling of safety properties, code generation, verification, and graphical debugging of failed 
properties. 


e We used COCOSIM fitted with this new capability to address Stateflow model compilation 
and verification on a set of industrial scale benchmarks and have experimentally evaluated 
our approach using two evaluation scales: (i) does the tool generate faithful code (wrt. 
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TIC { 
cent=cent+1; 


Running 

during: [cent==100] { 
disp_cent=cent; cent=0; 
disp_sec=sec; sec=sec+1; 
disp_min=min; 


cent=0; sec=0; min=0; 
disp_cent=0, disp_sec=0; 
disp_min=0; 


[sec==60] { 
sec=0; 
min=min+1; 


Figure 1: Stopwatch Stateflow model (from [14]). 


the intended Stateflow semantics)? and (ii) is the tool able to efficiently verify safety 
properties? In Section 5 we provide evidence that answers positively both questions. 


Synopsis. The paper is structured as follows. In the next two paragraphs, we first informally 
illustrate the Stateflow semantics and then give an overview of related works. In Section 2, we 
describe a CPS denotational semantics for Stateflow. In Section 3, we illustrate instantiations 
of the CPS semantics that allow us to generate both an interpreter and a code generator. Based 
on the code generator from Section 3, we describe in section 4 a compiler from Stateflow to 
Lustre automaton. Finally, in Section 5, we describe an open source implementation of our 
proposed technique and present the experimental evaluations that illustrate the effectiveness of 
our approach. 


Stateflow semantics. Let us look at a concrete example that illustrates different Stateflow 
constructs. Figure 1 shows the Stopwatch model capturing a basic behavior of a stopwatch. 
This system interacts with its environment via 3 signals: START, LAP and TIC. TIC models 
the time increment of the system. START and LAP events model the user interaction with 
the device. There are 2 top level states Run and Stop, and 4 inner states Reset, Lap_ stop, 
Running and Lap. The device is initialized in Stop mode and switches back and forth between 
Stop and Run. When in Running state, it can be paused using the LAP signal. Each TIC signal 
received when in Run state increments the timer, performing side effects on the internal timer 
variables (i.e., cent, sec, min). This specific behavior is modeled by a set of transitions using 
only junctions and starting with an inner transition. This model is interesting since it relies on 
multiple constructs of Stateflow: inner and outer transitions, junctions and hierarchical states. 


Related work. Despite its lack of formal semantics, Stateflow is widely used in the industry 
both for modeling purposes and code generation [23]. It has been studied for formal model- 
ing and verification by numerous approaches, e.g., targeting automata [4, 19, 33], hybrid au- 
tomata [2], process calculi such as CPS [6, 34], transition systems [23], tabular expressions [28] 
or the synchronous language Lustre [27]. As a general remark, each of these approaches makes 
some restriction on the considered language, e.g., on events, inner transitions or junctions, and 
synthesizes an encoding in the target language, supported by verification tools or test case 
generation, independently of the code generated from the same model. 
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An approach related to ours is the work described in [27]. This approach translates a State- 
flow model into Lustre dataflow language [5]. Since Lustre-like languages such as Scade [29] are 
used in the industry to generate embedded code, the approach is compatible both with compi- 
lation and verification. The approach is however very limited in respecting the full Stateflow 
semantics. A tool, sf2lus, is provided and performs the translation for the considered subset. 
This approach differs from ours in several ways: (i) Our translation keeps state machines struc- 
ture and by consequence makes it easy to read and traces state information; (ii) sf2lus handles 
events erroneously at the same time, which makes the behavior unsound wrt. Stateflow events 
semantics. Events occur (and wake the chart) in an ascending order based on their port num- 
bers once at a time. Such a chart can then be executed multiple times in the same time step; 
(iii) sf2lus does not support newer versions of Stateflow; and last (iv) our tool is developed in 
Matlab and is directly integrated into the Simulink /Stateflow environment, which allows among 
other features the use of Matlab simulation tool to further investigate failed properties. 

Another line of related works are developed in a series of papers by Hamon [14, 15] on 
which we based our work. In these papers, a formal semantics for Stateflow is provided, either in 
operational or denotational flavors. Notice that [32] starts from Hamon’s denotational semantics 
to define a structural operational semantics for three Statecharts languages, including Stateflow, 
but does not provide a compilation schema or analysis techniques. [30] uses a translation of 
Stateflow models to pushdown systems to generate and check invariants, but does not go further 
in properties to analyze. Until now, these are the only formal reference semantics available for 
Stateflow. 

Last, Simulink Design Verifier (SLDV) is a toolbox provided by Mathworks to perform 
automated formal analysis of Simulink/Stateflow models. However, SLDV is a commercial 
distributed tool, therefore details on implementation and functionality are not available to the 
public. 


2 Denotational Semantics for Stateflow 


In this section, we describe our first contribution: a continuation-passing style denotational 
semantics for Stateflow. We start from the syntax and denotational semantics” described in [14]. 
However, we will revisit such semantics using a continuation-passing style (CPS). This new 
formulation allows to directly and easily capture the intended semantics of Stateflow. We use 
a syntactic representation of Stateflow models described by the grammar presented in Table 1. 


Syntax. A program (8s, srcjef1...n]) is com- P == (s,[sreo,...,8ren]) 
posed of state definitions s : sd and junctions sr, i= si sd| 5:7 

j : T, with a main node s. A single state sd = ((ae,44,4z),T>, T;, C) 
is defined by the entry, during and exit ac- Co :s= Or (T,[so,.-.,8n]) 
tions (Ge, dq, @,), outer and inner transitions | Ad (isn - snl) 
T, and T;, as well as component content C. t = (e,¢, (a a d) 

A component content C is either an Or(T, sl) ef —> i LT oo 

state with initializing transitions T’ and sub- d z= pli 

states sl, or an And(sl) state where all sl sub- p s= Ol sp 


states are run in parallel. A transition list 


is an ordered sequence of transitions. Each Table 1: Syntactic representation of Stateflow 
models. 


?This syntax and semantics does not handle additional constructs such as loops, history junctions or call to 
external C functions. The restriction of covered constructs is further detailed in Sect. 5 
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main.run.running: ((Oa,disp = (cent, sec,min),Qa), 

(START, true, Qa, 0a, P main.stop.reset) ; 

(LAP, true, a,%a,P main.run.lap)], |], Or (J, )) 
main.run.lap: ((Oa,%a,Ga) ; 

(START, true, 92,92, P main.stop.lap_ stop) ; 

(LAP, true, a, a, P main.run.running)|, {], Or ([],)) 
main.run: ((Oa,%a,e)  {], 

(TIC, true, cent = cent + 1,0a, J j1)], Or ([], {running; lap})) 
jl: [(noevent, cent == 100, cont = 0;sec = sec+1,Qa,J j2); 
(noevent, cent! = 100, 0a,Qa, J 73)] 

j2: [(noevent, sec == 60,min = min+ 1,02, P main.run) ; 
(noevent, sec! = 60, 02,Qa, J 73)| 

ja: | 


Figure 2: Encoding of the Stopwatch Stateflow model using the syntax from Table 1. 


transition is associated with an event, a con- 
dition, side effect condition actions a,, transition actions a; and a destination d. Destinations 
could be either states or junctions leading to further transitions. 


Modeling Stopwatch example. Figure 2 describes the Stopwatch model using the syntax 
from Table 1. Transitions from a state s to another s’ are defined as outer T, and inner 
transitions T; of node s, depending on the target node. The transitions associated to a node 
content of type Or describe the initialization transitions when entering into the node. Junctions 
enable the definition of transitions combining multiple conditions. The semantics of transitions 
is far from trivial: a transition path is evaluated one segment (atomic transition) after the other, 
performing side effects on the state via condition actions a, on the go, while transition actions 
a; are only performed when all conditions over the path are satisfied and the path reaches a 
state not a junction. If a given path is eventually fireable, the exit actions of the original node 
are performed, then the transition actions, to conclude with entry actions of the target node. 


2.1 CPS Denotational Semantics for Stateflow 


Motivating Continuation-passing style. The denotational semantics presented in [14] 
relies on continuations to model the actions of path computation. Indeed, the actions associated 
to an atomic transition (a segment) are performed either immediately for condition actions and 
eventually for transition actions. Success and fail continuations allow to capture this complex 
behavior in functions, representing side effects as denotations. However, values manipulated 
by this denotational semantics were explicitly first order and represented by environments p of 
type Env: p::= {0 : U0,---,2Ln : Un, 80 : 00,---, Sk : by}. These environments represented both 
the values of variables x; and the active status of states s;. 

The encoding of [14] could be significantly improved by rearranging arguments so as to 
push environments in rightmost position and defining a pure continuation-passing style (CPS) 
denotational semantics, point-free wrt. environments. Indeed, in some situations, the author 
would drop continuations and evaluate explicit intermediate environments. 

The following definitions characterize our CPS denotational semantics for Stateflow, fol- 
lowing precisely the semantics of [14] while solving its flaws. The semantics is higher order 
and environments are never made explicit: the evaluation of a model component acts as a 
transformer. 
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Conditions. ‘Transitions in Stateflow are computed based on the current environment and 
an active event, evaluating conditions. Without loss of generality, we assume that the event 
is part of the environment and is not made explicit in the rules. An active event e could be 
checked as a regular condition using the predicate event (e). We recall that the environment 
contains both variables mapped to values and active status of Stateflow states. To clarify the 
expression, we made explicit the check whether a state characterized by p is active using the 
predicate active(p). 


Actions. The key ingredient of transition computation in Stateflow is the sequence of ac- 
tions applied on the current environment, updating values of variables and changing active 
and inactive states. Actions act as transformers and are the values manipulated by our CPS 
denotational semantics. We denote by Den this transformer type. 

Basic action constructors are left free here but typically express some imperative assign- 
ment of an expression to an environment variable. In addition, we introduce the actions open 
p and close p which switch the Boolean status of state p to true or false respectively. 
In order to generalize the approach, we express disjunctions as actions using the constructor 
Tte(condition, Den, Den). 

A primitive action (assignment or open/close action) semantics, i.e., its interpretation as 
a transformer, is defined using the function A[-] : action + Den. (Actions) transformers can 
be combined using the operator >>: Den + Den — Den, which is associative: a; >> az > az 
means that action a; is performed before action az followed by a3. Last, the default action, 
identity, is denoted Td. 


Denotational semantics as a functions map. Semantics functions are associated to state 
names and a global continuation environment 6 of type K Env is defined as follows: @ := 
{ p; : (Spi : sdi, 0, S[pi : sdi]¢ 0,S[p; : sdiJ®, 0), 9; : TIL;)6,---.5; : TIL;JO}. Functions 
Spo : sdo]®,, S[po : sdo]? and S|[po : sdo]%, denote respectively the semantics of a state when 
entering it, executing it, or exiting it. Note that entry and exit actions are parametrized by a 
mode m € Mode = L | S. This mode, either loose (L) or strict (S), captures the difference 
between inner and outer transitions for entry and exit actions. Junctions are associated to 
transition list semantics function 7. The @ map captures the semantics of all components of 
the Stateflow model and is typically provided as argument of denotations. 


Transitions semantics. Stateflow semantics is rather complex. A Stateflow transition 
amounts to evaluate a sequence of atomic transitions. Depending on some dynamic conditions, 
each atomic transition may be eventually fired or not. In all cases, it will impact the environ- 
ment through side effects (condition actions). We introduce three continuations: success of 
type k* := Den modeling a fired transition, a fail continuations of type k~ ::= Den modeling 
an unfired one and a third case fail9!? of type k~ capturing complex executions in which a 
series of junctions ends in a terminal junction. In case of a transition leading to another state, 
some entry or exit actions may be performed*. They are captured by the wrapper continuation 
of type w ::= p > Den > Den. 

The evaluation of a destination path which is a state amounts to apply the wrapper on 
the success continuation. Otherwise, when the destination is a junction, the transition list 
semantics is evaluated with the same continuations. 


D[p] (0: KEnv) (wrap: w) (success: k+) (fail fail9!e® :k-): Den = wrap p success 


3Note that those actions are not performed for a transition ending in a terminal junction. 
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P[j] 6 wrap success fail fail9'e> = 65(j) wrap success fail fail9'? 


Atomic transition semantics introduces an Zte action: in case of an unfeasible condition, the 
(regular) fail continuation is used, otherwise a new success continuation is built, evaluating the 
transition actions of the atomic transition. The action associated to the then-branch combines 
the condition actions followed by the new destination evaluation and relies on the newly defined 
success continuation. 

T[ (ez, ¢, (ac, at), d)] (0: KEnv) (wrapper: w) (success: k+) (fail fail9'°? :k-) : Den = 

Tte(event(ex) Ac, 

(let success’ = success >> (Ala:]) in 
(Alac]) >> (D[d] @ wrapper success’ fail fail9'°’)), 
fail) 

Evaluation of a list of transitions performs a left-to-right traversal of the list: the unfea- 
sibility of the head transition leads to the evaluation of the next, involving definition of fail 
continuations. As a special case, when provided with an empty list of transitions it always 
evaluates to the global fail continuation. 

T[O] (0: KEnv) (wrapper : w) (success: kt) (fail fail9!e’ :k-): Den = fail#' 
T[t.T] 9 wrapper success fail fail9!°? = 
let fail! =T[T] @ wrapper success fail fail9'°> in 


T[t] 6 wrapper success fail’ fail9!e® 


State semantics. State semantics involves the opening and closing actions of states. We 
introduce wrapper functions dedicated to inner, outer transitions, as well as entering of states. 

Wrapper considers a source and destination paths, p, and pg, and identifies the common 
prefix p of both paths. Depending on the context (inner or outer transition), it will compose 
respectively the exit actions of remaining p,, the transition actions continuation, and the enter- 
ing actions of the remaining pg. Outer transitions will involve loose state semantics while inner 
transitions involve strict one. A specific wrapper open_path® is introduced to enter substates 


of a path. 
open_pathY (0: KEnv) (p: Path) (ps: Path) (pq: Path): w= 
if hd(ps) = hd(pa) A hd(ps) #0 then 
open_path” 6 p.hd(ps) tl(ps) t1(pa) 
else match v with 
o -> Aden.0¥(p.nd(ps)) > den > 02 (p.hd(pa)) t1 (pa) 
i -> Aden.0%(p.hd(ps)) > den > 08 (p.hd(pa)) t1(pa) 
e -> Aden.den > 0¢ (p.hd(pg)) t1(pa) 


This definition assumes that hd and tl functions, returning head and tail of a list, are 
extended to handle empty lists, i.e., hd? =@ and t1 0 =9. 

We now define the core semantics functions of states, S lat 4 Note that mode parameter 
m is provided as an index. Entering or exiting a path executes the entry and exit actions of 
all states in the path, respectively. Depending on the outer or inner status of a transition, the 
entry or exit actions of the root node shall or shall not be evaluated. The following definitions 
capture Stateflow semantics, handling specificities such as transitions from a node to a child or 
parent. 
S[p : ((de,@a,4x),To,Ti,C)]& (0: KEnv) (0: Path): Den = (CI[C]® p 4) 


Ig 
SIp: ((ae, 44,42), To, TiC) 8 s.pa= (02(p-5) pa) 
Slp: ((ae,aa,ax),;To,Ti, C)]§ (0: KEnv): Den= (C[C]* p @) 


S[p : (de, aa, 4x), To, Ti, C)E, 
S[p : (de, ag, 4x), To, Ti, C)E, 
Sp: ((@e, aa, 4x), To, Ti, C)E 


Pa = (Alae] 9) > (Aopen p]) > (5 (p-s) pa) 


0 = (Alac] 0) >> (Alopen p]) > (C[C]® p 4) 
= (C[C]* p 0) > (Alaz] 6) > (A[close pl) 


ooo 
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The definition for during actions is the following. First outer transitions are evaluated. If 
none succeeds, the during action of the node is computed. Then, inner transitions apply. If no 
transition can be fired at all, the components of the node are computed. 


S[p : ((ae, ag, 4x),To,Ti,C)]J¢ (0: KEnv) : Den = 
let wrapper; =open_pathi 0 p in 
let wrappero =open_path® § p in 
let fail, = 
let fail; =C[C]¢ p 0 in 
(Alaa] 9) >> (T[Ti] 6 wrapper; Td fail; fail;) in 
T[To] 9 wrapper, Td failo failo 


Component semantics definitions follow. Entry transitions associated to an Or node initiate 
the component and shall not fail (the L value is unreachable). Execution or exiting of an Or 
component applies on the active element. Parallel states rely on fold_right to ensure proper 
function compositions. 


Or(T,0)]° p @=TZd 

Or(T,S)]& p 0=T[T] 8 (open_path® 0 p) Td 1 1 
Or(T,0)]4 p 06 = Id 

Or(T,2.S)]9 p 6 =Tte(active(p.x), 04(p.x),C[Or(T, S)]* p 6) 
Or(T,0)|* p 0=Td 

Or(T,«.S)]* p 6 = Tte(active(p.x), 0¥(p.x),C[Or(T, S)]* p 4) 
And(S)]® p 6= fold_right (Aw.Ares.0§ (p.x) 0 > res) S Td 
And(S)]* p @= fold_right (Az.Ares.0¢(p.2) > res) S Id 
And(S)]* p @= fold_right (Ag.Ares.6%(p.x) > res) S Td 


ARQVNAaagagaaa 


ee 


Program semantics. The evaluation of the main program produces a transformer: 
P[(s, Sres] : Den = Ite(active(s),04(s),0¢(s) 0) 


where @ is built using Srcs and initial environment assumes all states are inactive, including 
the main one, s. 


2.2 Comparison with Hamon’s denotational semantics 


The previous definitions are directly extracted from [14] but were modified to solve minor 
soundness flaws and to be compatible with the pure CPS semantics we designed. Without de- 
veloping much about the soundness flaws’, let us highlight the main differences in the semantics 
definitions: 


e we adapted the rule to match our understanding of non trivial Stateflow constructs, 
as exhibited by current Stateflow simulation engine. For example sequences of actions 
performed when leaving a state and entering another one follow a specific order: in [14] the 
use of success and fail continuations was improperly combined. Our encoding introduced 
a new argument wrapper used in D, 7 and 7. Open and close actions bind dedicated 
wrappers that reorder actions. Our version follows current Stateflow behavior. 


e regarding CPS, as explained at the beginning of the section, the p argument is abstracted 
away and gives rise to a point-free semantics. Every dynamic access to environment as 


4In fairness to this work, it is somehow difficult at the present time to figure out what the undocumented 
semantics of Stateflow circa 2005 may look like and to what extent it was well specified. The appendix sections 
compares the original semantics of [14] and the one we provide, both compared to the current behavior of 
Stateflow simulator. Notice also that [32] corrects some flaws in Hamon’s denotational semantics. 
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Alopen p](p) =p [pH true] Alopen p] = p=true 
Alclose p](p) =p [pH false] Alclose p] = p=false 
Alv =expr](p) =p [uv [ezpr],] Alv =expr] =  v=expr 
Tte(cond,T,E)(p)= if [cond], then T(p) Tte(cond,T,E)= if cond then T 
else E(p) else 
(D; > D2)(p) = D200 Di(p) (Di > D2)= Di; Do 
Td(p)= p Td= nop 
t= assert false t= assert false 
(a) Interpreter (b) Code Generator 


Figure 3: Instantiations 


found in Hamon’s work is removed. For instance, dynamic if-then-else statements are 
lifted to a dedicated constructor to postpone their execution; similarly action evaluation 
is always introduced within computed continuations and never evaluated directly (see e.g., 
T[-] and S[-]¢). This brings far more flexibility in the purpose and design of semantics 
functions and allows for instance to define interpreters, code generators, source to source 
transformations, etc. 


3 Modular code generation for Stateflow 


The formal semantics presented in the previous section can be instantiated with appropriate 
definitions for the primitive elements of the denotational semantics: A]-], Zte(-,-,-), >, L and 
Td. 

We present here different settings for the instantiation either as an interpreter or as code gen- 
erator. The next section will address our main goal: generate Lustre automata from Stateflow 
model while preserving the hierarchical structure model. 


Interpreter instantiation. The denotational semantics of [14] can be obtained where trans- 
formers modify environments: Den = Env > Env. Figure 3a details the associated defini- 
tions. An environment p defines a map from variables to values, including active status of states. 
piv — c] represents the substitution of a variable v to value c in environment p. We assume that 
[expr], represents the evaluation of expression expr in p, with a Boolean interpretation when 
evaluating a condition expression. The bottom construct throws an exception, but should not 
happen for well constructed models. We recall that events are part of the environment and are 
accessible through predicate active(e) using in conditional expressions. Such an instantiation 
provides a simulator for the model: when provided with an initial environment, it computes 
the successor environment. 


Code generator instantiation. One can also synthesize imperative code by synthesizing an 
abstract syntax tree while evaluating transformers. Den denotes here an abstract syntax tree 
(AST): 
Den s:= Den;Den 
| if cond then Den else Den 
| 


vu=expr | nop | assert false. 


Figure 3b provides such simple instantiation. Applying the code generator on the Stopwatch 
example from Fig. 1 generates a rather large program: about 800 LOC, for an overall number 
of 220 actions and 135 conditions, nested up to depth 13. 
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Preserving hierarchical structure. Stateflow semantics is global since environment. is 
shared among all states. However, the transitions are attached locally to states. We can 
preserve this hierarchical structure by associating a procedure to each state execution denota- 
tion: each call to the denotation 6°(p), 64(p) or @*(p) could be respectively substituted by a 
call to a procedure thetae_p, thetad_p or thetax_p instead of executing S[p : sd]°4* 0. This 
is possible since all arguments of these semantics functions are static (paths, modes, etc). 

For a program (s, srcs), the total code generation is then performed state by state, generat- 
ing procedures thetad_p for each state p declared in program sources srcs. The main procedure 
being the one associated to state s. For the Stopwatch example in Fig. 1, it generates 7 pro- 
cedures, for an overall number of about 270 LOC, 100 actions and 55 conditions, nested up to 
depth 7. We have implemented in OCaml an interpreter and a code generator instantiation of 
the CPS denotational semantics. The code can be found in [1]. 

In our approach, modularity is itself modular as we can choose either to turn every se- 
mantics function into a procedure or on the contrary to inline its results. In this respect, 
turning junction-related semantics function (7), which amounts to computing T[j : T] @ into 
a procedure helps in factorizing out common prefixes of transition sequences, provided one can 
defunctionalize [9] its arguments wrapper, success and fail, expressing as first-order values. 

For Stateflow models with complex transition sequences between junctions, this would 
greatly help factorizing out common junctions occurring in many paths, avoiding combinatorial 
blow-ups. This is left for future work. 


4 Stateflow models as Lustre automata 


In this section, we describe the compilation of Stateflow models into Lustre automata. Lustre [5] 
is a dataflow language, bearing similarities with Simulink/Stateflow, but is endowed with a 
synchronous semantics, which yields a more disciplined and predictable language, suited to 
verification activities. Lustre programs are expressed in terms of nodes, which directly model 
subsystems in a modular fashion, with an externally visible set of inputs and outputs. A node 
can be seen as a mapping of a finite set of input streams to a finite set of output streams. 
Operationally, a node has a cyclic behavior: at each clock tick t, it takes as input the value 
of each input stream at instant t and synchronously returns the value of each output stream 
at same instant ¢. A Lustre node is built from a set of dataflow equations of the form x = e 
where z is a variable denoting an output or a locally defined stream and e is an expression, in 
a certain stream algebra, whose variables are input, output, or local streams. Each variable is 
assigned exactly once at each cycle. Most of Lustre operators are point-wise lifting to streams 
of the usual operators over stream values. Still, a Lustre node may access to variable values at 
previous cycles, up to to a bounded past. 

Automata are supported since Lustre V6 [8, 7]. The overall behavior of an automaton 
is pictured in Fig. 4. An automaton consists of states, each with its own set of equations 
and possibly local variables. At each instant, two pairs of variables are computed: a putative 
state_im and an actual state state_act and also, for both states, two booleans restart_in and 
restart_act, that tell whether their respective state equations should be reset before execution. 
The actual state is obtained via an immediate (unless) transition from the putative state, 
whereas the next putative state is obtained via a normal (until) transition from the actual 
state. Only the actual state equations are executed at each instant. Finally, a state reset 
function is driven by the restart /resume keyword switches. A more complete presentation of 
these constructs is given in [11]. 

We are able to generate a Lustre AST mimicking the execution of the previous imperative 
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output 


state_act 
base clock 


Figure 4: Automaton as a pure dataflow. 


Alopen p] in out := out = in[in_p true] Lte(cond,T, E) in out := 
Alclose p] in out := out = in[in_p +> false] automaton nameuid 
Alv = expr] in out = out = in[in_v 6 [expr]in] state Cond: 

A[call p] in out := out — thetad p(in) unless [-cond]in restart NotCond 

(Li > Le) in out:= (Li in nameuia) let (T in out); tel 

(Lz nameuia out) state NotCond : 
Tain oe onan unless [cond]in restart Cond 
linout:= assert false let (E in out); tel 


node thetad_p (in : Tin) returns (out : Tour) 


let (S“[[p] in out); tel 


Figure 5: Lustre instantiation 


code. The translation is also modular: a Lustre node is built for each component and each 
condition within a component is turned into an automaton. The use of intermediate local 
variables in the Lustre source allows to make the control-flow explicit. The denotation is 
defined as Den = (Name > Name — LustreAST), taking two names in and out standing for 
input and output variables and producing a piece of code, assigning output from input. Lustre 
automata encode the very semantics of imperative conditional statements, whereas standard 
Lustre conditional is a strict operator which doesn’t suit our needs. This instantiation is 
presented in Figure 5, assuming a supplementary node call action call p. We denote by in and 
out the sequence of variables present_in the Stateflow environment, prefixed by names in and 
out respectively. Similarly, T;,, and T,,,, denote their respective types. 

Note that the action transformer function generates a set of Lustre flow definitions. Its 
evaluation combines all atomic transitions of Stateflow of an end-to-end transition into a single 
Lustre automaton state. No intermediate step is introduced. The language of actions is, for 
the moment, limited to basic Lustre flow definitions, but is left free in the general semantics 
of [16]. 


Main compilation schema. We have implemented this compilation as a component of the 
CoCoSIM tool framework. In order to illustrate how the compiler works, let us consider a 
simple example. Figure 6 presents a simple transition between two states A and B. Each state 
is compiled into a corresponding Lustre automaton state (suffixed with _ IDL). As Lustre only 
allows computations in states, the transition between A and B is compiled into a Lustre state 
that executes the transition actions. A _EXIT_B ENTRY thus represents the transition in 
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A B 
En: A_En E[C]{Ac}/At En: B_En 
Ex: A_Ex Ex: B_Ex 
automaton ab 
state CENTER_POINT: state A_EXIT_B_ENTRY: 
unless id=1 and E and C restart let 
A_EXIT_B_ENTRY; -- execute the actions: condition 
unless id=1 restart A_IDL; action, 
unless id=2 restart B_IDL; -- A exit action, transition action, B 
let entry action 
outputs = old_outputs; tel 
tel until true restart CENTER_POINT; 
state A_IDL: state B_IDL: 
let let 
outputs = A_during_action(old_outputs, outputs = B_during_action(old_outputs, 
inputs) ; inputs) ; 
tel tel 
until true restart CENTER_POINT; until true restart CENTER_POINT; 


Figure 6: A simple transition encoding. 


our example and contains all the actions to be executed: condition actions, exiting state A, 
transition actions and entering state B. id indicates the active state at the beginning of each 
clock. “Set B to active’ means “update id to 2”. The Lustre code associated to the previous 
transition A> B is presented in the same Figure. In order to make the presentation simpler, 
nested Ite constructs as synthesized by our CPS semantics have been merged into a single 
automaton with more states. 


5 Experimental evaluation 


In this section, we describe the implementation of our proposed approach as a component in 
the COCOSIM [17] tool framework. Moreover, we report the results from our experimental 
evaluation. 


5.1 CoCoSim 


CoCoS™ [17] is an open source automated logic-based analysis framework for Simulink models. 
CoCoSIM consists of two main components: (i) a compiler that compiles a subset of Simulink 
models to Lustre [5]; (ii) an interface to multiple model checkers based on Lustre. In this paper, 
we have extended COCOSIM to support compilation and verification of Stateflow models. The 
current version of COCOSIM provides capability to verify user supplied safety requirements. 
The CoCoSIM workflow is pretty straightforward: a user specifies a safety requirement (prop- 
erty) in the Simulink/Stateflow model. This is done using a synchronous observer method. 
Subsequently, COCOSIM can be called directly on the Matlab environment” and the result of 
the analysis is reported directly on the Simulink model. If the property is violated, COCOSIM 
reports the set of input values that leads to the error state. Such information is then used to 
simulate the model, which allows the user to debug why a property is failing. 


5The implementation in Matlab provides easy access to priorities for transition, typing information and eases 
the construction of traceability maps enabling the expression at model level of invariants or counter-examples. 
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Figure 7: (a) The overall architecture of COCOSIM. (b) A screenshot of a verification scenario 
of a Stateflow model using COCOSIM: part (A) shows the Stateflow model; part (B) is the 
synchronous observer block, where the property to be verified is specified; part (C) is the 
CoCoSIM dropdown menu provided as a Matlab toolbox. 


The analyzer as well as the traceability information of the CoCoSim toolchain produces 
both a complete environment to simulate the model in Simulink as well as the sequence of 
active Lustre states and Lustre transitions computed, leading to a violation of the property. 
The computation of the associated list of Stateflow states and transitions could be rebuilt from 
that information. This is left as a future work. 

The verification technique via observer-based method was first introduced by Halbwachs et 
al. [13], where a safety property of an I/O machine M is defined in terms of another machine 
called a synchronous observer. The observer watches the inputs and outputs of M, and if 
they ever violate the safety property it emits an alarm signal. Various work has been devoted 
in applying the observer-based method in different areas, e.g., [31]. In [25], Rushby explains 
how observer-based methods are quite versatile. For instance, they can be used to increase 
expressiveness, specify assumptions and axioms, but also to generate test cases. Synchronous 
observers are specified using the same language as the system under test. This is means that 
the user of COCOSIM can specify the desired requirements using Simulink blocks. Its main 
novelties can be summarized as: (i) It decouples the input language syntax from the under- 
lying verification technique; (ii) It provides a convenient way to express safety requirements; 
(iii) It allows the combination of automated logic-based verification results with traditional 
Matlab based tools; and finally, (iv) it offers a convenient way to debug failed properties. An 
important aspect of COCOSIM is its ability to simplify the development and integration of new 
analysis techniques targeting Simulink/Stateflow models. This is accomplished via a modular 
architecture (see Fig. 7a). 


Supported Stateflow blocks Our implementation in COCOSIM version v0.1 supports most 
known Stateflow constructs such as: states (Exclusive (OR) and Parallel (AND) states), most 
used state actions (entry, during and exit actions), transitions with the following transition 
labels: event only, event and condition, condition only, action only or event and condition 
and action combined. In addition to these constructs, COCOSIM supports default transitions, 
inner and outer transitions, self-loop transitions, inter-level transitions, connective junctions 
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and history junctions. COCOSIM also supports basic data types (int, real and booleans) and 
also arrays with static indexes (e.g., [2]). More specific charts ° are supported such as: flow 
charts, Stateflow functions (graph functions), Hierarchical states, enter, exit, send and after 
operators. 

The current version of COCOSIM does not support events emission in actions (state action 
or transition actions); it supports instead the send operator that can replace events emission. 
We also assume that the model does not have an unbound behavior (such as loop in junctions). 
In addition, transitions with more than one event are not yet supported’. 


Datatypes. Our work focuses on providing a global semantics to Stateflow, which we believe 
is hard enough. We do not address specific details such as how to represent Simulink datatypes 
in the target language Lustre. Several simple solutions nevertheless come to mind. One could 
provide each of these types in the form of an external Lustre library, totally hiding their im- 
plementations, at the cost of making explicit all the implicit coercions at work in the Simulink 
semantics. Another solution would be for instance to map every specifically-sized integer type 
to the unspecified Lustre integer type (that is what we currently do) and then to annotate the 
Lustre program in order to take care of sizes when generating C code or Horn clauses. 


5.2 Experimental evaluation 


We have performed a set of experimental evaluations to demonstrate the effectiveness of Co- 
CoSiIm. Our experiments are carried out in a machine with the following specifications: Intel 
Core i5, 8Go RAM, 750Go HD, with Ubuntu 16.04. We used COCOSIM v0.1 which runs on 
Matlab 2014b and up, however, in this experiments we used Matlab 2016a with Stateflow version 
8.7. 

The first experiment was performed in order to illustrate the soundness of our compilation 
scheme. In particular, we would like to answer the question “how faithful is the code generated 
via COCOSIM?”. In order to answer this question, we have compared the C code generated via 
CoCoSim with the one generated by Mathwork’s Simulink® Coder™™ [21]. The latter is a 
popular product routinely used in different industrial application for code generation. Specifi- 
cally, we have used a set of randomly generated test vectors with 100 iterations to validate the 
code generated by COCOSIM against the one generated by Simulink® Coder™™. Such valida- 
tion process is given as an option in COCOSIM. This allows a user to validate that the compiled 
code via CoCoSim conforms at least with the code generated by Simulink® Coder™™. It 
also allowed us to demonstrate that other translation tools such as sf2lus [27] do not respect 
the full Stateflow semantic comparing to ours. 

In our experiments, we have used a set of 77 Stateflow models ® to evaluate the soundness 
and runtime of the compilation. Fig. 8a shows the size of the different models: number of actions 
is the sum of all state actions (entry, exit and during actions), condition and transition actions 
in the model. Fig. 8b illustrates the amount of time the compiler took to generate first Lustre 
code and then Horn clauses (used for verification). The models are given in decreasing number 
of actions, we can easily observe that generation time increases with the number of actions of 
the models. On average, COCOSIM takes about 1.85s to generate Lustre code. Fig. 8c shows 
the times for the validation script. On average, the validation process takes about 3.35s. 


Shttps: //github.com/coco-team/regression-test 

7We are working on CoCoSim v0.2 to support: external C functions call and Matlab code, Arrays, On_ event 
action and others. 

Shttps://github.com/coco-team/regression-test 
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Figure 8: Runtime and validation experiments of COCOSIM. 


models # 7 safe # Hf safe unsafe 
props unsafe | timeout | (time) (time) 
Microwave 15 15 0 0 65.51 0 
NasaDockingApproach 4 3 0 1 360 0 
GPCA_ System _ Monitor 1 1 0 0 0.64 0 
GPCA_ Logging 1 1 0 0 4.88 0 
GPCA_Top_Level_ Mode 3 3 0 0 36 0 
GPCA_CONFIG 1 0 1 0 0 19.34 
GPCA_INFUSION_ MGR 7 5 0 2 596.51 0 
GPCA_ Alarm 8 0 6 2 0 281.12 


Figure 9: Experimental results of safety verification on a set of use cases. 


5.3 Safety verification 


The second experiment was performed in order to illustrate the effectiveness of our approach 
for the verification of safety properties. We have used 3 set of use cases. The first one is 
a Stateflow model of a microwave that captures the modal behavior of a typical microwave 
control software °. COCOSIM were able to verify 15 properties of this model using the backend 
solver Zustre [10] as the backend solving engine. The second use case is a Stateflow model that 
captures the complex behavior of the Space Shuttle when docking with the International Space 
Station (ISS) [26]. As the shuttle approaches the ISS, it goes through several operational modes 
related to how the shuttle is to orient itself for capture, dock with the ISS, and capture the 
ISS docking latch, among several other operational modes. The model describing this behavior 
is quite intricate and consists of a hierarchical and parallel state machines with three levels of 
hierarchy and multiple parallel state machines, including a total of 64 states. Using COCOSIM 
we were able to verify 2 out of 4 safety properties. 

The third use case is the Generic Patient Controlled Analgesic infusion pump system. It 
consists of four main components: Alarm, Infusion, Mode and Logging. A more detailed descrip- 
tion of the model can be found in [12]. Figure 9 summarizes the safety verification experimental 
evaluation results using COCOSIM. 


°This model is developed by Rockwell Collins 
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6 Conclusion 


In this paper, we have described an automated technique for the formal analysis of Stateflow 
models. Our approach faithfully compiles Stateflow models into hierarchical state machines, and 
uses automated logic-based verification engine to decide the validity of safety properties. We 
capture the compilation process using continuation-passing style (CPS) denotational semantics. 
Our compilation technique preserves the structural and modal behavior of the system, making 
the safety analysis of such models more tractable. We have presented a preliminary experimental 
evaluation that illustrates the effectiveness of our approach in the safety verification of industrial 
scale Stateflow models. 
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A Semantics of stopwatch example 


We illustrate here the output of the stopwatch example as defined in Figures 1 and 2 when used 
with our Ocaml interpreter. 

Interpreter. When provided with a simple sequence of events |[VNO_ EVENT; START; TIC, 
it produces the following changes of active states. Note that a first step without provided event 
setup the model in its initial active state. We call ./sf_sem -model stopwatch -eval 2 


HHH main -> true HHA 
main -> false main.stop -> true — Event TIC — 
main.run -> false main.stop.reset -> true — action performed — 
main.run.lap -> false cent+=1 
main.run.running -> false HEH cent==100 
main.stop -> false — Event START — cont=0;sec+=1 
main.stop.lap_stop -> false —no action performed — sec=—60 
main.stop.reset -> false main.run -> true sec=0; min+=1 
main.run.lap -> false disp=(cent,sec,min) 
HHHD main.run.running -> true 
— Event none — main.stop -> false « no state changed » 
—no action performed — main.stop.reset -> false 


Code generator. We can also produce imperative-like code using the instianciation of Fig- 
ure 3b. In our prototype, the modularity is tuned at three different levels: (i) no modu- 
larity at all, generating about 600 lines of code; (ii) modular with respect to S%, ie. for 
each state of the automaton, generating about 270 lines of code including seven functions fo- 
cused on each state behavior; (iii) last, modular for each element: entry, during, exit actions, 
generating about 328 including 23 functions for each set of actions: entry, during or exit ac- 
tion of each state. We present here an excerpt of the code obtained with the second option: 
./sf_sem -model stopwatch -modular 1 -gen_imp 


principal = if Active(main.stop.reset) 
if Active(main) then <CallD(main)> then <Close(main.stop.reset)> 
else <Open(main) >; else if Active(main.stop.lap_stop) 
if true then <Open(main.stop)>; then <Close(main.stop.lap_stop 
if true then <Open(main.stop.reset) )> 
> else <Nil> endif 
else bot endif; 
endif <Close(main.stop) >; 
else bot <Open(main.run)>; 
endif <Open(main.run. running) > 
endif else if Event(LAP) then <reset 
sae counter > 
component CallD(main.stop.reset) = else <Nil> endif 
begin endif 
if Event(START) then end 


The generation of Lustre is even more verbose: 2713 loc for inline calls, 1154 loc for state 
modular Lustre generation and 1132 with the fully modular model. We do not present here 
such generated code but refer the reader for the tool website to evaluate it. The generated is 
compatible with our tool LustreC and therefore can be used either to generate embeddable C 
code or to perform model-checking analyzes with our tool Zustre. 
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